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A programmable logic controller (21) has an equivalent network interface module (35) for permitting direct communicative 
coupling of the programmable logic controller (21) to a data conununication network (23), sudi as Ethernet The equivalent ne- 
twork interface (35) contains a mailbox register (39) for holding messages and a communications processor (37) for controlling 
the operations of the equivalent network interface (35) while the remaining section of the programmable logic controller (21) con- 
tains a control processor (31) for regulating the operations of the controller (21), a scan processor (33) for scanning the controB- 
er's (21) ladder program and an image table (32) for holding data used by the scan processor (33). 
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AN EQUIVALENT NETWORK INTERFACE MODULE FOR 
CONNECTING A PROGRAMMABLE LOGIC CONTROLLER 
TO A HIGH SPEED COMMUNICATIONS NETWORK 

DESCRIPTION 

5 Technical Field 

Applicants* invention relates to microproces- 
sor based devices and, more particularly, to a an 
equivalent network interface module for connecting 
a programmable logic controller to a high speed 

10 communications network, such as Ethernet. 

Related Applications 

This application is related to commonly as- 
signed co-pending applications. Docket Nos. AP0031, 
"A System for Sharing Data Between Microprocessor 

15 Based Devices"; AP0032, "A System for Processing 

Alarm Notifications in Microprocessor . Based 
Devices"; AP0033, "Apparatus for Networking Program- 
mable Logic Controllers to Host Computers"; and 
AP0034, "Emulation of a Programmable Logic Con- 

20 troller by a Host Computer". 
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Background Prior Art 

As industrial automation advances, inter- 
connectivity between various microprocessor based 
plant floor devices, such as programmable logic 
5 controllers ("PLCs") , and plant computers, becomes 
more and more desirable. For example, the extensive 
math and register commands of a PLC can perform data 
pre-processing on raw data right at the raw data's 
point of origin, as opposed to uploading all of the 

10 raw data to the host computer, thereby permitting 
use of a smaller host computer. 

Various schemes have been developed to inter- 
connect PLCs and host computers, but their applic- 
ations have been limited. For example, if one 

15 wanted to communicatively couple three PLCs in the 

absence of a network, each PLC would typically 
recpiire a separate serial, or point to point, 
connection with each of the other two PLCs. How- 
ever, the speed of serial communication is limited. 

20 Further, as the number of interconnected PLCs grows 

linearly, the number of serial connections grows 
geometrically. 

In a commonly assigned co-pending patent 
application. Serial No. 180,093, a peer-to peer 

25 system is disclosed for interconnecting a plurality 

of PLCs. However this system requires a dedicated 
communication network. 

Allen-Bradley Company, Inc. , in conjunction 
with Digital Equipment Corporation ("DEC") has 

30 developed a system marketed xinder the trade name 

"Pyramid Integrator" for interconnecting devices 
over the relatively standardized Ethernet network 
via DEC'S VAX* computer. However according to this 
system, only a maximum of four PLCs can be coupled 

35 to an Ethernet network per VAX computer, and each 

of the PLCs must be plugged into the backplane of 
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the VAX compmr. If five PLCs are reqxilKd on the 
Ethernet, two VAX computers are required. This 
greatly adds to the expense of automation. 

In addition, a host computer can concurrently 
5 perform a plurality of applications programs, or 
user tasks. When a PLC is connected to such a host 
computer, it is often important for the host com- 
puter to obtain data from the PLC. Typically this 
is accomplished by having the host computer poll the 

10 PLC. However, this polling either requires the host 

computer to interrupt the PLC's processing of its 
ladder .program, or it requires the host computer to 
wait for the PLC to complete a scan of its ladder 
program* Further it is often important for the PLC 

15 to send unsolicited information to the host com- 
puter . 

Messages typically are transmitted between 
microprocessor based devices on an Ethernet network 
in the form of data packets » The data packets 

20 generally include a preamble portion comprising 
routing information and protocol type, a user 
defined portzion comprising the message itself, and 
an error detection portion. As the speed of commun- 
ication between microprocessor based devices 

25 increases, error detection operations become ever 

more critical. Typically the error detection 
operation views the entire data packet to determine 
existence of an error. This often does not quickly 
enough detect errors in the user data portion. 

30 Further, the protocol often cannot accurately 
respond to lost messages. 

Finally as automated systems control ever 
larger operations, handling and prioritizing of 
event notifications or alarms, such as faults, 

35 alerts and warnings, by the host computer becomes 

even more important. While certain host computers 
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have been able to receive aXarms, they have been 
receiv d on a global basis, rather than individually 
on a user task basis. 

Applicants* invention is provided to solve 
these and other problems. 
Summary of the Invention 

It is an object of the invention to provide an 
apparatus for interconnecting PLCs and other micro- 
processor based devices over a high speed communica— 
tions network, such as Ethernet. 

It is a further object of the invention to 
provide a system wherein a host computer can im- 
mediately obtain data from a PLC without inter- 
rupting execution of the PLC's ladder program and 
wherein the host computer can receive unsolicited 
information from the PLC. 

It is a still further object of the invention 
to provide a communication protocol including high 
speed error detection of the user data portion of 
a data packet. 

It is yet another object of the invention to 
provide a communication protocol which can accu- 
rately respond to lost messages. 

Finally, it is an object of the invention to 
provide a system which prioritizes alarms, such as 
faults, alerts and warnings, while also allowing 
for an essentially unlimited number of alarms per 
gueue. 

Other features and advantages of the invention 
will be apparent from the following specification 
taken in conjunction with the following drawings. 
Brief Description of Drawings 

Figure l is a block diagram of a plurality of 
microprocessor based devices coupled to a high-speed 
communications network; 



Figur is a more de1:ailed bl diagram 

illustralzing sof'tware architecture of a host com- 
puter and a PLC, each coupled to the high-speed data 
communications network; 

Figur 3 is a software data flow diagram 
illustrating important elements in the communi- 
cations architecture of the system; and 

Figure 4 is a graphic illustration of the 
communication buffer of Figure 3. 
Detailed Description 

While this invention is susceptible of embodi- 
ments in many different forms, there is shown in the 
drawings and will herein be described in detail, a 
preferred embodiment of the invention with the 
understanding that the present disclosure is to be 
considered as an exemplification of the principles 
of the invention and is not intended to limit the 
broad aspects of the invention to the particular 
embodiment illustrated • 

A first programmable logic controller ("PLC") 
21 coupled to a high-speed data communications 
network 23 is illustrated in Figure X. other 
microprocessor based devices such as a host computer 
25 or other microprocessor based devices 27, 29 can 
also be coupled to the communications network 23* 
The host computer 25 can be a VAX® computer, sold 
by the Digital Equipment Corporation, and the PLC 
21 can be a SY/MAX® Model 650 programmable control- 
ler, sold by Square D Company, assignee of this 
patent application. 

The communications network 23 comprises a Thin 
Wire Ethernet (Type 10BASE2) lOMbaud network. The 
host computer 25 can couple directly to the Thin 
Wire Ethernet network with an appropriate Thin wire 
Ethernet interface (not shown) , or it can attach to 
a standard Ethernet (Type 10BASE5) network which is 
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then connected through a repeater (not shown) to the 
Thin wire Ethernet network. 

Up to 100 microprocessor based devices can be 
connected to the coimnunications network 23. A 
5 standard Thin Wire Ethernet network may have up to 

30 devices attached,. If a multi-port Thin Wire 
repeater is used, however, each of the repeater 
ports can have a 29-device network attached. All 
the Thin Wire and standard Ethernet networks 
10 connected through the repeater are logically part 

of the same network^ therefore drop numbers (dis- 
cussed below) used must be unique across the whole 
network. This is how up to 100 microprocessor based 
devices can be connected to the one communications 
15 network 23. 

One such repeater is a DEC model DEMPR-AA 
multi-port repeater which has one 15-pin transceiver 
cable connector and eight Thin Wire connectors. 
Another repeater is a DEC model DESPR-AA single-port 
repeater, which has one 15-pin transceiver cable 
connector and one Thin Wire connector* The 15-pin 
transceiver cable is used to connect the repeaters 
to a standard thick-wire Ethernet. The DEMPR-AA and 
DESPR-AA count as one Thin Wire network drop on each 
25 network to which they are attached, so up to 29 

microprocessor based devices can be attached to each 
port. The repeaters do not require drop numbers; 

The first PLC 21 includes a control processor 
31 (Motorola 68010) , an image table 32 and a scan 
30 processor 33 (AMD 29116) . Traditionally PLCs have 

required a separate network interface module (or 
"NIM") in order to communicate on a high-speed 
communications network such as Ethernet. In accor- 
dance with one aspect of the invention^ the first 
35 PLC 21 includes an equivalent network interface 

module (ENIM) 35. The ENIM 35 comprises a com- 



20 
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munications^fccessor 37 (Motorola 68010^md random 
access memory operable as an ENIM mailbox register 
39. As discussed below, the ENIM 35 is coupled to 
the communications network 23 via a first port 35a. 
5 A two-port RAM 41 has first and second ports 

43, 45, respectively. The first port 43 is coupled 
to the ENIM 35. The second port 45 is coupled to 
a data bus 47* The data bus 47 is also coupled to 
the control processor 31, the image table 32 and the 
10 scan processor 33. The control processor 31 acces- 

ses the two-port RAM 41 via the data bus 47. The 
control processor 31 transfers data from the two- 
port RAM 41 to the image table 32, which is accessed 
by the scan processor 33. Thus, the ENIM 35 and 
15 the control processor 31 exchange data via the two- 

port RAM 41. 

The mailbox register 39 provides random access 
registers to permit the first PLC 21 to receive 
unsolicited messages from other devices coupled to 
20 the communication network 23 without affecting 

operation of the scan processor 33. Unsolicited 
messages can also be received directly in the image 
table 32, but this requires interruption of the scan 
processor 33. Typically messages are first placed 
25 directly into the ENIM mailbox register 39 and then 

are moved into the image table 32 at predetermined 
times by the scan processor 33. Only critical 
unsolicited messages, such as a stop bit to stop 
the scan processor 33, are placed directly into the 
30 image table 32. 

Software architecture of the host computer 25 
as viewed by a user is illustrated in Figure 2. 

As indicated above, traditionally a PLC re- 
quired a network interface module (NIM) to communi- 
35 cate over a high-speed data communications network. 

Such a NIM typically had only a single high-speed 
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port^ adaptable to cdimnunicatively couple to the 
network, and a serial port. Thus, in order to 
communicate between two networks, two separate NIHs 
were required so that each of the two high-speed 
5 ports could be coupled to a respective one of the 

networks. The two NIMs would then be jointly 
coupled by their serial ports. According to the 
invention, the host computer 25 is provided with 
software architecture including a network to network 
10 (net-to-net) software bridge which permits PLCs and 

other similar devices coupled to the communications 
network 23 to communicate directly with user tasks 
within the host computer 25 as though the user tasks 
were simply other PLC's on the communications 
15 network 23. Accordingly, such other PLC's are able 

to request data from the user tasks while the user 
tasks are running. 

As discussed above , host computers have been 
able to poll specific PLCs coupled thereto for 
20 information, though such polling has required either 

interruption of the PLC's scan cycle, or waiting for 
completion of the PLC's scan cycle. However, these 
traditional host computers have been unable to 
obtain unsolicited messages from a PLC. Further, 
25 a host computer typically concurrently runs a plur- 

ality of user tasks. Sometimes it is desirable for 
unsolicited information from a PLC to be available 
for all of these concurrently running user tasks. 
At other times, it is desirable that the unsolicited 
30 information be available for only one, or a limited 

ntunber, of these concurrently running user tasks. 

Accordingly, the host computer 25 illustrated 
in Figure 2 operatively includes software architec- 
ture comprising a dispatcher (or software bridge) 
35 52, a system task 53, system task operating memory 

53a, a global mailbox register 54, and first, second 
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and third tasks 55, 57 and 59, r^^^ctively. 

The dispatcher 52 accepts and routes data transfers 
between the user tasks 55, 57 and 59, the system 
task 53 and other devices on the communications 
5 network 23. The dispatcher 52 thus acts as an 
intermediary between the system and user tasks 53, 
55, 57, 59, and the physical communication channel 
operating as the communications network 23 in a 
manner transparent to the system and user tasks 53, 
10 55, 57, 59, 

The host computer 25 further includes a global 
alarm. queue 60. Specifics of the software archi- 
tecture are discussed below with respect to Fig- 
ure 3. 

15 As viewed in Figure 2, each of the first, 

second and third user tasks, 55, 57 and 59 includes 
respective first, second and third user task oper- 
ating memory 55a, 57a, 59a, wherein operating data 
is stored, as is well known. Each of the first, 

20 second and third user tasks, 55, 57 and 59 further 

includes respective first, second and third user 
task mailbox registers 61, 62, 63, and a respective 
tLrsii, second, and third alarm queue 64, 65, 66. 
Each of the first, second and third user tasks 55, 

25 57, 59 is communicatively coupled to the dispatcher 

52 by a software bus 67. The dispatcher 52 is a 
server program and includes first and second network 
modules 69, 71 and a host configuration table 72. 
The first and second network modules 69, 71 coop- 

3 0 erate as an ENIM between the communications network 

23 and the software bus 67. Specifically, the first 
network module 69 and second network module 71 
emulate two back-to-back hardware NIMs which tradi- 
tionally, as described above, had been used to 

35 interconnect two networks. The first and second 

modules 69, 71, permit the PLCs on the network 23 
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to communicate with selected ones of the user tasK^ - 
55, 57, 59 as though they were just other PLCs* 

E)evices on the communications network. 23 are 
operatively located at "drops". In order to route 
5 a message from one device to another, a routing 
address is added to the message indicating where the 
message is from (originating drop number) , where the 
message is going (destination drop number) and the 
path for the message to get there (routing drop 

10 nximber) • For example, the first PLC 21 is located 

on the communications network 23 at a drop "5", and 
the host computer 25 is located on the communi- 
cations network 23 at a drop The first user 
task 55 is located at a drop "6", the second user 

15 task 57 is located at a drop "8", and the third user 

task 59 is located at a drop "9". The global 
mailbox register 54 and the global alarm queue 60 
are aissigned a drop number of 100 plus the drop 
number, of the computer 25, in this case being "107". 

20 The global mailbox register 54 and the global alarm 

queue 60 have the same drop number. Data to be sent 
to the global mailbox register 39 is distinguished 
from data to be sent to the global alarm queue 60 
by the particular register address. 

25 The task mailbox registers 61, 62, 63, and 

their respective alarm queues 64, 65, 66, are 
assigned the drop number of their respective device. 
For example, the first user task mailbox register 
61 is located at drop number "6". Therefore, the 

30 first user task mailbox register 61 and the first 

user alarm queue, have the drop number "6". As with 
the global mailbox register 54 and the global alarm 
queue 60, the user task mailbox registers 6i, 62, 
63 have the same drop numbers as their respective 

15 user alarm queues 64, 65, 66. Data to be sent to 
one of the user task mailbox registers 61, 62, 63 
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their respective user alarm queues 64, 65, 66, by 
the particular register address. 

Two locations in the first PLC 21 are aJbl& to 
receive and store data, that being the mailbox 
register 39 and the image table 32. In order to 
route information from the two-port RAM 41 to the 
global mailbox register 54, one uses the routing 
address (5, 107). The number "5" of the routing 
address (5, 107) represents the location of the 
origination of the data, in this case being the 
device coupled to drop number "5". The number "107" 
of the routing address (5, 107) is the address of 
the global mailbox register 54. 

The mailbox registers of the individual PLCs 
on the communications network 23, such as the 
mailbox register 39 of the first PLC 21, are as- 
signed an address nujuber "200". When routing data 
to a particular ENIH mailbox register, such as the 
mailbox register 39, the number "200" precedes the 
drop number of its respective drop location. For 
example, if data is to be transferred from the first 
^ser tas)c 55, to the mailbox register 39, the 
routing would be (6, 7, 200, 5). The number "6" of 
the routing address (6, 7, 200, 5) indicates the 
location of the origination of the message, in this 
case being the drop number of the first user task 
55- The number "7" of the routing address (6, 7, 
2 00, 5) represents the exit from the software bus 
67. The number "200" of the routing address (6, 7, 
200, 5) indicates that the data is going to a PLC 
mailbox register, and the ntimber "5" of the routing 
address (6, 7, 200, 5) indicates that it is the PLC 
mailbox register of the PLC coupled to drop number 
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If imsolicited register data is to be available 
for each of the user tasks 55^ 57, 59, the message 
is routed to, and stored in, the global mailbox 
register 54. However, if the unsolicited register 
5 data is only for one of the user tasks, such as the 
first user task 55, the message is directed to the 
first user task mailbox register 61. Similarly^ if 
the message is for a selected, limited number, 
though not all, of the user tasks, the unsolicited 

10 register data would be sent to the mailbox registers 

of the selected, limited number of the user tasks. 
Similarly, the first PLC 21 or other similar devices 
on the communications network 23 can also obtain 
data from the individual user task mailbox registers 

15 61, 63, 65, or the global mailbox register 54. 

Software resident in the host computer 25 supports 
the user task mailbox registers 61, 62, 63 and the 
global mailbox register 54 ^ 

The user task mailbox registers 61, 62, 63, are 

20 requested and specified when the respective user 

task first connects to the dispatcher 52. The host 
configuration table 72 is a block of 1000 registers 
coupled to the second network module 71. As indi- 
cated above, the first network module 69^ and second 

25 network module 71 emulate two back-to-back hardware 

NiMs. Therefore, as with the ENIM 35, the host 
configuration table 72 has an address of "200" 
followed by the drop number of its respective drop 
location, which in this case would be (200,7) . The 

30 host configuration table 72 specifies protocol data, 

such as response time-outs, retries and the like. 

Measures such as slave response timeouts, reply 
timeouts and message retries are utilized to limit 
the inherently non-deterministic nature of the 

35 Ethernet network. These measures allow a user to 

specify a maximum time to wait for a message to be 
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deliv red, i^ft reply to be received, wi^feit error, 
effectively providing deterministic behavior on the 
network. 

Each of the user tasks 55, 57, 5^ can have up 
5 to 8192 user task registers numbered in the range 
0001-8192. Three of the registers from each of the 
user tasks 55, 57, 59, form the respective alarm 
queues 64, 65, 66, and the remainder of these user 
task registers from each of the user tasks 55, 57, 

10 59, form the respective user task mailbox registers 
61, 62, 63. The particular mailbox register numbers 
are specified by its respective user task. Start 
and end register numbers of start and end registers 
can be anywhere in the range, if fewer than 8192 

15 registers are needed. For example, lOOO mailbox 

registers could be numbered 1234-2233, if desired. 

Each of the user tasks 55, 57, 59 can access 
its own respective mailbox register 61, 62, 63 in 
either of two ways, specifically by (1) indexing 

20 into an array or (2) with read/write register 
commands. 

Indexing into an array is the most efficient 
way, as it is the user task's own mailbox register 
which is being read. Accordingly, the particular 
25 one of the user tasks 55, 57, or 59 specifies memory 
blocks in random access memory (RAH) of the host 
computer 25. These specified memory bloclcs are used 
as mailbox registers, and the particular user task 
can access the specified memory blocks as an array 
of 16-bit register values. In the example above 
(mailbox registers 1234-2233), the user task reads 
its mailbox register 1235 by reading the second word 
of the register array (memory block) . 

The second way of accessing a user task's own 
mailbox register is similar to reading any other 
mailbox register in that a read/write register 



30 



35 
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conmtand (a cotomand by a user task to r ad or write 
to a particular register) is utilized. This is less 
efficient than the first way of a user task acces- 
sing its own mailbox register, discussed immediately 
5 above, as read or write subroutines must first be 

called. With read/write register commands, an empty 
route field of a register coiomand (the terminator 
is the first entry) indicates that reads and writes 
will refer to the user task's own mailbox registers « 

10 A 2 -drop route field in a register command is 

used to read and write to other task*s local mail- 
boxes • A 3-drop route field is used to read the 
global mailbox 54; the middle number of the 3-drop 
route field being the drop number of the host 

15 computer 25 and the last number of the 3 -drop route 

field being the number "100" plus the drop number 
of the host computer 25. 

The actual software architecture is illustrated 
in the data flow chart of Figure 3. The system task 

20 53 architecturally appears simply as another one of 

the user tasks, thus the following discussion with 
respect to the first user task 55 applies as well 
to the system task 53. Reference numbers common to 
Figure 2 have been maintained. 

25 Messages from one of the user tasks 55, 57, or 

59 to another of the user tasks 55, 57, or 59, or 
from the communications network 23 or the system 
task 53 are routed through the dispatcher 52, as 
follows. 

30 Each of the tasks, user tasks as well as system 

task, includes a respective per-process mailbox, 
such as the first per-process mailbox 80 associated 
with the first user task 55. The per-process 
mailbox 80 is used as a signaling mechanism to 

35 inform the respective tasks that a message is 

available. Messages sent via the per-process 



wo 91/14988 - 1 5- PCr/L'S91/01918 

mailbox 80 simply a prompt; only a m bytes of 
pertinent data are actually transferred via the per- 
process mailbox 80. The actual message is placed 
into and temporarily stored in a communication 
5 buffer 82. 

The communication buffer 82 performs the 
function of the software bus 67 (Figure 2) and is 
illustrated in Figure 4. The communication buffer 
82 is part of the virtual memory RAM of the host 

10 computer 25, which is allocated by the software of 

the host computer 25 under control of the dispatcher 
52. .The communication buffer 82 includes reply 
input queue pointers and command input queue point- 
ers for each of the tasks, user as well as system, 

15 such as the first reply input queue pointers 84 and 

the first command input queue pointers 86 which are 
associated with the first user task 55. The command 
input queue pointer 86 stores memory addresses of 
command messages directed toward the user task 55, 

20 and the reply input queue pointer 84 stores memory 

addresses of reply messages directed toward the user 
task 55. The respective reply input queue pointers 
and command input queue pointers operate similarly 
for their respective tasks. Reply messages have a 

25 higher priority than command messages, therefore the 

communications buffer 82 distinguishes reply mes- 
sages from command messages so that reply messages 
can be processed first* 

The communications buffer 82 further includes 

30 dispatcher queues, specifically dispatcher input 

queue pointers 88 and free list queue pointers 94. 
Additionally, the communication buffer 82 includes 
message buffers 96. 

The message buffers 96 are memory locations for 

35 storing messages. The dispatcher input queue 

pointers 88 identify locations in the message buffer 
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96 for messages received from *the various ones dfr- 
the tasks, user as well as system. The free list 
queue pointers 94 identify unused (ie, available) 
locations in the message buffer 96. Messages 
5 received from the communications network 23 are 
given a higher priority than messages from the tasks 
to lessen the chance of missing a message from the 
communications network 23* 

Referring again to Figure 3, the per-process 

10 mailbox 80 is simply a VMS (VAX software) mechanism 

for sending a prompt, indicating that a message is 
waiting. Data in one of the per-process mailbox 
registers interrupts the particular one of the tasks 
associated with the one of the per-process mail- 

15 boxes, causing the particular one of the tasks to 

read the message, command or reply, located at the 
address stored in its respective reply and/or 
command input queue pointers in the communications 
buffer 82. 

20 Messages are similarly transferred from a task 

to the dispatcher 52. However because the dis- 
patcher 52 does not distinguish between reply and 
command messages, only one queue is required. 

To send a command message from one of the user 

25 tasks, the particular user task obtains an available 

message buffer from the free list queue pointers 94 • 
. To send a reply message from one of the user 
tasks, the particular user task uses the same buffer 
which the command message was delivered in. In this 

30 way there will never be the situation where there 
are no free buffers to accept the reply message. 

The particular one of the user tasks then 
writes the message data into the message buffer, and 
queues the message on the dispatcher input queue 

35 pointer 88. If the dispatcher input queue pointer 

was empty, a prompt is sent to a dispatcher, prompt 



wo 91/14988 - 1 7- PCX/ US9 1/0 191 8 

i&ailbox 98 t^^ndicate a presence of a n^j^message . 

The dispalicher 52 will process the messag s iden- 
tified in the dispatcher input queue pointer until 
none are left. 

5 For messages to be transferred from the dis- 

patcher 52 to the commimications network 23 (ie. 
outbotmd Ethernet messages) , the dispatcher 52 
passes the address of the message to an Ethernet 
driver 97. The dispatcher 52 includes a pending 
10 outbound message pointer 52a and an inbound message 

queue pointer 52b. The pending outbound messages 
queue pointer 52a identifies message buffer loca- 
tions for messages to be transmitted on the com- 
munications network 23. The inbound message queue 
15 pointer 52b identifies message buffer locations for 

messages to be transferred from the dispatcher 52 
to one of the tas)cs, user as well as system . 

The host computer 25 must be able to relisibly 
deliver messages. Messages may not be dropped 
20 except for extraordinary circumstances. 

When a command message must be delivered to 
the first user task 55^ the dispatcher 52 will queue 
the command message to the command input queue 
pointer 86. If the command input queue pointer 86 
25 is empty, a message prompt will be sent to the first 

user task's 55 per-process mailbox 80. If the first 
user task's command input queue pointer 86 is not 
f^llf the message is queued, and no prompt is sent. 
If the particular task specified by the routing 
30 address is not connected to the dispatcher 52, an 

error reply is generated. The error reply is sent 
to the source of the command message. 

One does not want to overwhelm a particular 
task with commands such that the particular task 
35 cannot respond to commands as quickly as they are 

received, as this conceivably could result in 
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filling all of the available conununication buffers, 
which could then also back-up other ones of the 
tasks. Although this has not been found to be a 
problem in practice, it is contemplated, that an 
5 error command could be generated if such did occur. 

Unsolicited messages can be accepted by the 
tasks, user as well as system* These messages can 
read and write data to the local mailboxes and write 
alarms to the local alarm queues 

10 Mailbox registers and alarm queues (both local 

and global) can also be used to implement data 
sharing between application programs. However, 
tasks will only respond to alarms, and read/write 
of the task mailbox registers. Other functions will 

15 result in error replies being returned to the 

sender. 

The present invention also provides for prior- 
itization and response to alarms by the host com- 
puter 25, both on a global level as well as on a 
20 user task level. Alarms on the global level are 

accessible by any one of the user tasks 55, 57, 59, 
while alarms on the user task level are only acces- 
sible by that particular one of the user tasks 55, 
57, 59. 

25 As discussed above, the dispatcher 52 is 

provided with a global alarm queue 60. The global 
alarm queue 60 has three levels of alarm sub-queues, 
specifically a global fault alarm queue 60a for 
storing global fault alarms, a global alert alarm 

30 queue 60b for storing global alert alarms and a 

global warning alarm queue 60c for storing global 
warning alarms. 

In addition, each of the first, second and 
third user alarm queues 64, 65, 66 includes three 

35 similar user level alarm sub-queues, 64 a,b,c, 65 

a,b,c and 66 a,b,c, respectively. Each of the user 
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level alar^^ib-queues can receive an^lfeirm of up 

to 128 16-bit registers. 

An alarm queue entry ^ whether global or user- 
level, contains the following information: 
5 1. a reference number 

2. a time-stamp indicating the time the alarm 
was received by the host computer 25; 

3. a routing address (the route from origin-- 
ator to destination) ; 

^0 4. level of alarm (ie. fault alarms, alert 

alarms and warning alarms) ; 

5, a user specified alarm code; and 

6. user specified data. 

The allowed number of alarms per queue and the 
15 number of user data registers is determined by the 

user, depending upon an anticipated number of alarms 
as well as available memory • Each of the user tasks 
55, 57, 59 can perform the following functions in 
response to alarms in their own alarm queues as well 
20 as the global alarm queue: 

1- Read first alarm - get alarm data for 1st 
(ie., oldest) alarm in a queue; 

2. Read specific alarm - get alarm data for 
an alarm, specified by the reference number of a 

25 particular alarm; 

3. Read next alarm - get alarm data for the 
alarm with a reference number greater than (i.e., 
newer- than) a reference number specified; 

4. Clear alarm - delete an alarm from a 
3 0 queue ; 

5. Clear and acknowledge alarm - acknowledge 
and delete an alarm from a queue; 

6. Clear all alarms - delete all alarms from 
a queue; 

7. Clear and acknowledge all alarms - ack- 
nowledge and delete all alarms from a queue; 
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8. Set alarm notify - set up for task notifi- 
cation on addition/deletion of an alartn to/ from a 
queue/ and 

9 • Read alarm queue information get inform-* 
5 atipn about an alarm queue. 

As previously indicated, there are three types 
(levels) of alarm sub^queues: fault queues; alert 
queues; and warning queues* In general, the seve- 
rity of an alarm condition dictates which alarm sub- 
10 queue the alarm is posted to, with fault alarms 

being the most severe and warning alarms being the 
least severe • 

An alarm is written to an alarm queue, by 
another device, by issuing a write-register command 
15 to the particular register, based on the queue to 

be written. In the present embodiment, these 
"pointer" registers are: 

1. register number "8101" for a fault alarm; 

2. register number "8102" for an alert alarm; 

20 and 

3. register number "8103" for a warning 
alarm. 

Thus, a fault alarm to be sent by the PLC 21 
at drop number "5" to the first user task alarm 

25 queue 64 would have the routing address (5, 7, 6). 

and would be written to register number 8101. 

Generally, an alarm acknowledgement is sent 
back to the same register, in the device issuing 
the alarm, as the queue to which the alarm was 

30 written, though this can be overridden if the user 

desires to send an acknowledgement to a different 
register. 

The first register value in the data field of 
an alarm write-register is an alarm code to be 
35 posted, and the remaining register values are 

support data for the alarm. The amount of support 
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data for a^fcrticular alarm is contro^Kd by the 

user's application and needs and can range from o 
to a user-specified maximum number of registers. 
A complete alarm write-register command, such as 
5 from the PLC 21, would contain: 

1. a routing address from the device sending 
the alarm to the alarm queue location; 

2. an alarm "opcode" indicating an alarm 
operation to be performed; 

3* the sending device's status register ad- 
dress, which does not effect the alarm writing 
process ; 

4. the alarm cpieue register address (8101, 
8102, or 8103) as the destination of the write reg- 
is ister; 

5. the alarm code for the particular alarm; 

and 

6. any support data particularly desired by 
the user (O or more user specified registers) . 

The dispatcher 52 further includes a config- 
uration file 52c comprising a disk file that the 
dispatcher 52 reads when it starts running to 
determine a number of operating parameters, such as 
the drop number of the host computer 25. As indi- 
25 cated above, the drop number of the global alarm 

queues is the drop number of the host computer 25 
plus 100. Therefore, the route of an alarm write 
operation would have the drop number of the host 
computer 25 plus 100 as the last route number. 

Each alarm queue entry is time-stamped with 
the current time of the host computer 25 when it is 
written to an alarm queue. Additionally, each alarm 
queue entry is given a unique reference number for 
identification. If an attempt is made to write an 
35 alarm to an alarm queue that is already full, a 
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standard error code, such as "alarm buffer full"';* 
is return d In a priority-write reply message. 

The three global alarm queues 60^^ 60b, 60c are 
specified when the system task 5S is initially 
5 started up, usually upon system boot. The length 

(number of entries) and width (maximum number of 
support data registers) of these alarm G[ueues are 
specified in the configuration file 52c and can be 
modified only by shutting down the dispatcher 52, 
10 modifying the configuration file 52c, and restart- 

ing the dispatcher 52, such as by re-booting the 
system. If the length of the global alarm queues 
is specified as O, no global alarm queues are creat- 
ed. 

15 Any external device or internal task can write 

to the global alarm queues, and any internal task 
can view, clear, and acknowledge alarms from the 
global alarm queues. 

Each of the user tasks 55, 57, 59 has an option 

20 of setting up three alarm queues for itself. This 

is done when the particular one of the user tasks 
first "connects" to the dispatcher 52. These local 
alarm queues can only be read by the particular one 
of the user tasks; however alarms can be sent to the 

25 local alarm queues from anywhere on the system. The 

user task's drop number, which is also specified 
when the user task connects to the system task 53, 
is used as the last route number in the route field 
address of an alarm write operation. The second — 

30 last route number is the drop number of the host 

computer 25. 

Any external device or internal task can write 
to a user task's local alarm queues, but only that 
particular user task can view, clear, and acknow- 

35 ledge such an alarm. 
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Any pai^^ular one of the user ta^^ 55, 57, 
59 has an option of being "interrupted" when an 
alarm is added or removed from each of its three 
alarm queues. Alarm notification can be turned on 
5 or off for each of the alarm queues (fault, alert, 

and warning) and operation type (addition and 
removal) . Global and user task alarm queues are 
accessed independently. 

Alarm addition notifications occur when an 
10 alarm is added to a specified queue. Similarly, 

alarm removal notifications occur when an alarm is 
removed from a specified queue. This includes when 
a user task clears an alarm from one of its own 
queues if it has alarm removal notifications set on 
15 that queue. 

The user tasks cannot be interrupted while 
their interrupt routines are executing. Alarm 
notifications will be stacked, and each call to the 
interrupt routine will consist of only one notif ic- 
20 at ion event. 

The "interrupt" takes the form of a user-provi- 
ded subroutine that is called when any of the 
desired alarm queue operations takes place. When 
a user task connects to the dispatcher 52, the 
25 particular user task specifies which alarms to 

interrupt on, plus the interrupt routine address. 
A default is provided which causes no interrupts to 
be generated. 

The user task can also change the interrupt 
30 routine while running, so that changes to the 

interrupt routine address can be made 'on the fly« . 
All alarm notification interrupts for a particular 
one of the user tasks must use the same interrupt 
routine. 

35 Data passed to the interrupt routine includes: 

1. queue location - global or local; 
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2. (jueue type - fault, alert, or warning; 

3. queue operation - alarm added or alarm 
removed ; and 

4. reference number of the alarm. 

5 The reference number of an alarm is useful even 

if the interrupt is an alarm removal. For example, 
this would allow an alarm display to remove cleared 
alarms from a video display screen (not ' shown) 
without having to re-read the entire alarm queue 

10 contents • 

The system task 53 maintains a table of inter- 
rupt notification settings for any of the user tasks 
that require notification of global alarms. The 
table will accommodate notification information for 

15 up to 100 tasks. There can be no more than 100 

tasks connected to the system task 53 at any time. 

To assure accurate data transmission over the 
communications network 23, a high perf oinuance, 
positive acknowledgment retransmission commuiiication 

20 protocol has been provided. This communication 

protocol is used by any of the processor based 
devices on the communications network 23, including 
the host computer 25, that wish to exchange inform- 
ation . 

25 For each message correctly received by a 

receiving device, a positive acknowledgment, or 
"ACK", is returned to a sending device on the 
communications network 23 sending the message. If 
the receiving device receives an incorrect message, 

30 the receiving device will attempt to send a negative 

acknowledgment, or "NAK", back over the communic- 
ations network 23. Both ACKs and NAKs contain a 
transmission number of the last message successfully 
received by the receiving device. 

35 To guarantee that a message or its corres- 

ponding acknowledgment does not get lost, a timer 
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is provided .^fcsie tim r determines if sending 
device waited long enough for an acknowledgment 
(ACK) to be returned. The length of time that the 
sending device waits is user determinable. 
5 The protocol has the following features: 

1. A route address. Each device on the com- 
munications network 23 that is to communicate with 
this protocol must have an unique route address. 
The route address of the PLC 21 is set by using a 

10 four-bit rotary switch, and four DIP switches located 

on the PLC 21. For other devices on the communica- 
tions network 23, the route address can be set by 
the software of the particular device. The route 
addresses can range from 00 to 99. 

15 2. A transmission number. Each device that 

is to communicate with this protocol must keep track 
of the next transmission nximber it will send to each 
of the other devices on the communications network 
23* The transmission numbers help insure error- free 

20 data transfer. The numbering of the transmission 
numbers is cyclic^ from 0 to 254. The transmission 
number is initialized at the number 255. 

3. Pipelining. Each device that is to com- 
municate with this protocol allows additional 

25 messages to be sent while awaiting an acknowledgment 

of each of the messages previously transmitted. 
Accordingly^ a positive acknowledgement not only 
confirms that the specified message had been recei- 
ved correctly, it also specifies that all previous 

30 unacknowledged messages to the particular device 

were also received error- free. 

4. An "ACK" implied in a "NAK". All ackno- 
wledgements contain the transmission number of the 
last message successfully received from a particular 

35 device, thus allowing a negative acknowledgement 
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(KAK) t:o also provide posi1:ive acknowledgments of 
earlier messages* 

Each device on the communications network 23 
maintains an address table of known active route 
5 addresses as well as Ethernet addresses. The 

address table is used to correspond the route 
address of each device with its corresponding 
Ethernet address. 

Ethernet addresses have a length of 48 bits. 

10 As specified in IEEE Std. 802.3, the least sig- 

nificant bit specifies if the message is for a 
single device (bit=0) or if the message has a 
multicast address (bit==l) . A multicast address can 
be received by a plurality of devices on the com- 

15 munications network 23. The second least signif- 

icant bit in the Ethernet address is used to dis- 
tinguish between locally (bit=l) or globally (bit=0) 
administered addresses. A globally administered 
address indicates that the following 22 bits' have 

20 been assigned by the above IEEE standard. All 

communications with this protocol use globally 
administered addresses* 

The PLC 21 can generate its own Ethernet 
address, consisting of an assigned block of addres- 

25 ses and a value generated from the rotary and DIP 

switches. However, the Ethernet addresses of other, 
devices (i.e., host computers or other PLCs unable 
to generate an Ethernet address) are not automa- 
tically known. 

30 There are two methods to obtain the Ethernet 

addresses that are required to establish communic- 
ation on the communications network 23. According 
to the first method, a single multicast (i.e., a 
message containing a multicast address) CONNECT mes- 

35 sage is sent over the communications network 23 

after start-up. This CONNECT message allows all of 
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the devices "if^ are currently on the coni:^fe.cations 
network 23 to place the Ethernet address of the new 
device in their respective Address tables. 

Th devices on the communications network 23 
5 that receive the CONNECT message do not return a re- 

sponse. After they place the source's Ethernet and 
route address in their Address table, they discard 
the CONNECT message. The source of the CONNECT 
message, after sending the CONNECT message, is then 
10 able to transmit and receive other messages over the 

communications network 23. 

All devices physically must be connected to the 
communications network 23 before their Ethernet 
Driver is installed. If the user fails to follow 
15 this procedure, the devices on the communications 

network 23 will not receive the CONNECT message of 
a new device. Any device that wishes to communicate 
with the new device will then need to get the new 
device's Ethernet address by using a GET ADDRESS 
20 command, described below. 

With the CONNECT message , only the devices that 
are currently listening on the communications 
network 23 will know the Ethernet address of any new 
device. Consequently, a second method of estab- 
25 lishing Ethernet addresses is provided to commu- 

nicate with this protocol. This second method uses 
a GET ADDRESS request, a multicast message that is 
actually a superset of the CONNECT message. 

The GET ADDRESS REQUEST is transmitted whenever 
30 a first device, already established on the communic- 

ations network 23, needs to transmit a message to 
a new device having a route address that has not 
been established in the Address table of the first 
device. The GET ADDRESS REQUEST is also received 
35 by all devices that are communicating with this 

protocol. Though each device on the communications 
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network 23 will receive the message, the messagV ' 
will indicate which particular one of the devices 
should return a response. The remainder of the 
devices on "Uie communications network 23 store the 
5 Ethernet address and route address of the new device 

in each of their Address tables and discard the 
message. 

The GET ADDRESS REQUEST is only used to es- 
tablish the addresses of the devices oh the coinmuni- 
10 cations network 23. The GET ADDRESS REQUEST does 

not contain any data destined for an end device or 
task. Once the addresses of the devices on the 
communications network 23 are established, data can 
be sent to the end devices or tasks. 

i5 The device that responds to the GET ADDRESS 

REQUEST (the responding device) stores the route 
address and Ethernet address of the source device 
issuing the GET ADDRESS REQUEST in its Address 
table. The responding device then sends a multicast 

20 GET ADDRESS RESPONSE. This GET ADDRESS RESPONSE 

allows all other devices on the communications 
network 23 to update their Address table with the 
addresses specified in the GET ADDRESS RESPONSE. 
The GET ADDRESS REQUEST and GET ADDRESS RESPONSE^ 

25 as well as all other multicast messages, will not 

be acknowledged. If a GET ADDRESS RESPONSE is 
incorrectly received, a timeout will occur and a GET 
ADDRESS REQUEST will be retried. 

In the event the GET ADDRESS RESPONSE is not 

30 returned within a timeout period (defined to be the 

greater of 5 seconds, or 4 times the time that a 
device should wait for an acknowledgement) , the GET 
ADDRESS REQUEST will be sent again. If, after 8 
retries of the GET ADDRESS REQUEST, a GET ADDRESS 

35 RESPONSE is Still not received, all messages for 

this route address will be eliminated and, for 
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commands , responses will be reliu^l^d to the 

originating device or task* 

When a message that is destined for a device 
that exists in the Address table needs to be trans- 
5 mitted, the Ethernet address of that device will be 

used. By using the Ethernet address, only the 
specified device will receive the message. The 
first data containing message that will be sent will 
have a 255 as its transmission number. 

10 Each of the devices on the communications 

network 23 has a Transmit Queue, a Receive Buffer, 
and an Unacknowledge Queue dedicated to its Ethernet 
port. Also, variables for the amount of time a 
device should wait for an acknowledgement, the next 

15 transmission number to be sent, the next trans- 

mission number to be accepted, and the number of 
times a message should be retried must be kept for 
every route address. 

If there is a new message in the Ethernet 

20 transmit queue and the device for which the message 

is destined is defined in the Address table, the 
following steps should be used: 

1. For each new message, a variable for the 
next transmission nvimber to be sent for the par- 

25 ticular route address is placed in the data field 

of the message. The transmission variable is then 
incremented and stored back in the device's memory. 

2. The retry count is initialized to o and 
is stored in the message. 

30 3. After a message is to be transmitted, a 

timeout value is calculated from using the current 
time and the timeout time for the route address the 
message is intended for. This timeout value is 
stored along with the message in an unaclcnowl edged 

35 message queue* 



wo 91/14988 



-30- 



PCr/US91/01918 



4. After a message is sent, the Ethernet 
transmit queue is reexamined to see if there are 
any other messages for this device. If other 
messages exist, the transmitter will perform steps 

5 1 - 3 on new messages (without waiting for an 

acknowledgment of the original message) . The only 
exception to this step is if there are 254 outs- 
tanding messages to a particular device. For this 
case, the transmitter will be required to hold any 
10 new message until an aclcnowledgement is received to 

a previous message. 

5. After transmitting a message(s) , the 
device needs to examine if a timeout has occurred. 
This examination continues until either an ack- 

15 nowledgment for the message (s) is received or a 

timeout error occurs. 

6. If a timeout error occurs, or if a NAK is 
received that is not due to a lack of buffer space, 
the retry count for this message is examined. If 

20 the device has sent the number of retries specified 

for the destination route address, an error handler 
is invoked. If the device is to re-send the mes- 
sage, a retry count (located in the message) is 
incremented and the message is sent again. A 

25 timeout error will cause a single message to be 

retried, provided the retry limit has not been met. 
A NAK, however, can cause multiple messages to be 
^^tried, depending on the transmission number that 
is sent with the NAK. 

30 When an Ethernet packet is received, it must 

be examined to determine if it is a new message or 
an acknowledgment. If the packet is an acknowl- 
edgment, the following steps should be used,* ass- 
uming that the corresponding addresses have been 

35 previously placed in the Address table: 
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1. Ej^lftne the transmission numb^^returned 

in the acknowledgment • For the specific route 
address, if there is any message in the unacknovled- 
ge m ssage qu ue with an transmission number earlier 
5 or the same to what was returned, eliminate the 

message. The messages that are eliminated have been 
positively acknowledged by the corresponding device . 

2. Examine if the acknowledgment is an ACK 
or a NAK. If an ACK, processing is complete. If 

10 a NAKr deteirmine which message caused the error 

(returned in the NAK packet) . Assuming the retry 
count has not reached its limit, perform the follow- 
ing: 

a. Retry all messages that are in the unack- 
15 nowledge queue and were transmitted before the 

message that caused the NAK. 

b. Retry the message that caused the NAK if 
it is still in the unacknowledge queue. 

c. If the message that caused the NAK is to 
20 be retried, retry messages that are in the unacJcnow- 

ledge queue and were transmitted after the message 
that caused the NAK. For all NAKs, the reason for 
the failure is included in the message packet. if 
the NAK was due to insufficient room in the respon- 

25 ding device's buffers, the device which sent the 

message should not increment its retry co\mt. 

If the packet is a message, the following steps 
are followed. Note that these steps cause an 
acknowledgement to occur. Mhen any device has both 

30 acknowledgements and messages in its Ethernet 

transmit queue, the acknowledgements are transmitted 
first. This allows the device that sent the message 
to either purge the message from its unacknowledge 
queue (if an ACK was received) or retry the message 

35 (if a NAK was received). 
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1. Checlc if any errors were generatied while 
the message was received. If an error occurred that 
indicates unreliable data in the message, purge the 
message from the buffer. 
5 2. If the message was received without any 

noted errors, get the route address and the trans- 
mission number from the message and compare the next 
transmission number to be accepted for this route 
address to the transmission number from the message* 
10 If the two values are not the same, return a NAK 

with the value of the last transmission nvunber ac- 
cepted and purge the message from the buffer. 

3. If the message was received without any 
errors being noted and the transmission number from 
15 the message is the value that was expected (after 

comparing it against the next transmission number 
to be accepted for this route address) : 

a. return an ACK with the transmission number 
from the message; 
20 b. update the next transmission number to be 

accepted ; and 

c. process the message. 

In order to permit pipelining (the ability to 
send more than one message without- waiting for ACKs 

25 to each successive message) , discussed sU3ove, the 

description in the above step 3 must be expanded. 
For pipelining to occur, an ACK must not only 
confirm that the specified message has been received 
correctly, but that all previous messages with 

30 numbers between the one acknowledged in the last ACK 

and the one acknowledged by the current ACK have 
been received correctly. This is accomplished by 
examining the transmit queue after each new message 
is received. If an ACK is in the transmit queue for 

35 the same device, update the transmission number that 

is to be sent with the ACK. 
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It wil^Ve ixnderstiood that the in^ntion luay 
be embodied in other specific forms without depar- 
ting from the spirit or central characteristics 
thereof. The present examples and embodiments, 
therefore, are to be considered in all respects as 
illustrative and not restrictive, and the invention 
is not to be limited to the details given herein. 
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CIAIMS 

1. A progranmable logic controller for 
communication on an Elihernet data communication 
network, said programmable logic controller inc- 

5 luding integral means for directly coupling to said 

Ethernet communications network. 

2. The programmable logic controller of claim 
9 wherein said direct coupling means comprises an 
equivalent network interface module, 

10 3. A programmable logic controller (PLC) for 

communicatively coupling to a data communications 
network to send and receive messages, said PLC 
comprising: 

a control processor; 

15 an equivalent network interface module inc- 

luding a communications processor and a first port, 
said first port adapted to couple ^o said communi- 
cations network; and 

a mxilti-port RAM coupled between said control 

20 processor and said equivalent network interface 

module • 

4 . The PLC of claim 3 wherein said equivalent 
network interface module includes a mailbox regi- 
ster. 

25 5. The PLC of claim 3 wherein said messages 

include routing addresses and said equivalent 
network interface module includes means responsive 
to said routing addresses for directing said mes- 
sages . 

30 6. The PLC of claim 3 wherein said communi- 

cations network comprises Ethernet. 

7. The PLC of claim 3 wherein said communi- 
cations network exhibits non-deterministic behavior 
and said PLC includes means for limiting said 

35 nondeterministic behavior. 
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of claim 3 wherein sai^^^nde1:er-* 

ministic behavior limiting means comprises for 
specifying a maximum time for waiting for receipt 
of a message. 

5 9. The PLC of claim 3 wherein said nondeter- 

ministic behavior limiting means comprises for 
specifying a maximum time for waiting for a reply. 

10. In a programmable logic controller having 
a scan processor cuid a control processor for exe- 
10 cuting a series of program steps, an improvement 

for permitting direct communicative coupling of the 
programmable logic controller to a data communi- 
cations network, the improvement comprising: 

an equivalent network interface module, said 
15 equivalent network interface module including a 

communications processor, a random access mailbox 
and a first port, said first port adapted to couple 
to said high speed communications network; and 

a multi-port RAM coupled between said control 
20 processor and said equivalent network interface 

module. 
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